Session Initiation Protocol (SIP) is an open signaling protocol for establishing many kinds of real-time communication sessions. Examples of the types of communication sessions that may be established using SIP include voice, video, and/or instant messaging. These communication sessions may be carried out on any type of communication device such as a personal computer, laptop computer, Personal Digital Assistant, telephone, mobile phone, cellular phone, or the like. One key feature of SIP is its ability to use an end-user's Address of Record (AOR) as a single unifying public address for all communications. Thus, in a world of SIP-enhanced communications, a user's AOR becomes their single address that links the user to all of the communication devices associated with the user. Using this AOR, a caller can reach any one of the user's communication devices, also referred to as User Agents (UAs) without having to know each of the unique device addresses or phone numbers.
SIP is a flexible protocol that allows for the optional support of a wide range of features through the use of specific headers, methods and call-flows. With this inherent flexibility in the protocol and the relatively immature state of implementations available (when compared to other long established technologies), it is inevitable that devices will be deployed to a network that cannot take full advantage of all the features available on the network. This is because the devices will not necessarily implement all of the required headers or call flows that the network features require. It is not practical to expect an application to cater to all different types of endpoints and their varying degrees of support for the features offered. It is clear, therefore, that there is a problem in providing a network solution that allows for applications or features of varying complexity to be used by endpoints that do not natively support the call flow or header set required.
An example of this problem involves a solution to a long standing problem with Back-to-Back UAs (B2BUAs). A B2BUA is an often used architecture whereby a B2BUA application is sequenced during call setup into the signalling path between the caller and the callee. It looks like and acts as the real endpoint to both the caller and callee. The problem with this configuration is that a B2BUA may end up hiding the real call information from each endpoint. That is, as the caller endpoint is really in a call with the B2BUA and not with the callee endpoint, it does not know how the callee views the call. There are many features in SIP that rely on this endpoint view information being known by the endpoints. Without the proper endpoint view information, such SIP features either become broken or are inaccessible by the endpoints.
Continuing with the B2BUA example, a recent solution that resolves the problem of incorporating a B2BUA between endpoints is known as the Endpoint View Header. In this instance, both the caller and callee endpoints embed their view of the call in a header call the “Endpoint-View” header which passes transparently through the network so that the endpoints can become aware of how the other endpoint views the call. However, this is a recent proposal and there are many endpoints available today that want to exist in a network that contains a B2BUA but do not implement support for the “Endpoint-View” header. A similar problem arises in connection with other SIP headers and extensions to SIP behaviour.